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REMARKS 

In the current Office Action the Examiner has rejected claims 2-4, 8-10 and 12-15, 35 
USC 112, second paragraph, as indefinite, claims 12-15, 35 USC 101, as non-statutory, and 
claims 7 and 12, 35 USC 103, as unpatentable over Liao 'a IEEE Conference paper and La 
Porta patent 6,434,134. The grounds of rejection of claim 1-4, 8-10, and 13-15 are discussed 
below. Claims 7 and 12 are being cancelled. However, since the present invention is an 
improvement on the prior Session Initiation Protocol (SIP), applicants believe it would be 
helpful to the Examiner initially to discuss this protocol and its terminology. Further, in 
response to the Examiner's query as to the showing of a SIP-EYE Agent in Figure 3, 
applicants apologize for the confusion that may have been caused by the depiction of this 
symbolically as an eye, which is certainly not true in actuality. Accordingly, applicants are 
submitting a revised Fig. wherein the SIP-EYE Agent is shown as a computer readable 
medium, such as a cylinder within the mobile station and which contains executable 
instructions. Applicants are also amending the text of the specification to clarify this and 
define the SIP-EYE Agent more precisely. 

SIP is a protocol that transfers signaling data between network elements through 
messages. SIP messages are either requests or responses. SIP requests contain methods, and 
SIP responses contain status of requests conveyed back through status codes. Messages and 
methods are defined in the published SIP specification. Section 6 of RFC 3261 ( which is 
now the current specification replacing the prior RFC 2543 referred to at page 1 of applicants* 
application and which was the SIP specification existing when this application was filed) 
defines "message" and "method" as follows: 

Message: Data sent between SEP elements as part of the protocol, SIP 
messages are either requests or responses. 

Request: A SIP message sent from a client to a server, for the purposes of 
invoking a particular operation . 

Response: A SIP message sent from a server to a client, for indicating the 
status of a request sent from the client to the server. 

Method: The method is the primary function that a request is meant to invoke 
on a server. The method is carried in the request message itself. Example methods are 
INVITE and BYE. 

As can be seen, Method" and "message" are intimately related and, in fact, in the SIP 
community they are often used interchangeably. Applicants have amended the specification to 
clarify the actual distinction between "message" and "method** in SIP. Further, where in the 
application reference may be made to "a method or message", such as a "SIP INVITE method 
or message 71 , it is to be understood that what is intended is a "message containing SIP INVITE 
method". Applicants have amended the application at page 27, specifically noted by the 
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Examiner, to more precisely state this distinction between a message and a method in the SIP 
system, both as priorly existing and known to persons skilled in this ait and as improved by 
applicants' present invention. Claims 2 and 7 have also been similarly amended. 

With respect to claim 2, SEP INFO is a standard method of SIP that is used for 
communicating mid-session signaling information along the signaling path of the call Jt is 
now specified in RFC 2976 which was not finalized at the time of the filing of this 
application, but was then available to the art as an Internet Draft (draft-ietf-sip-info-method- 
02. at). In a nutshell, consistent with the above discussion, using a SIP method means sending 
a SIP request method containing an INFO method involving a function (e.g., address binding) 
and receiving a SIP response message back containing the status of the INFO request (e.g., 
sending a 200 OK response message confirming the address binding). 

With regard to the Examiner's discussion of prior claim 3, that claim has been 
amended clearly to recite the nature of the SIP-EYE Agent, as discussed above. 

The Examiner has also questioned the recitation of a SIP Register method, in claims 4, 
9, and 14. The SEP REGISTER method is a standard method in SIP and is described briefly at 
page 24, lines 4-10 of applicants' application. Thus SIP REGISTER is the standard method of 
Session Initiation Protocol (SIP) and is specified in the various SIP specifications, specifically 
now in RFC 3261 which, as noted above, has obsoleted the RFC 2543 referenced in this 
application. The SEP REGISTER method comprises many fields including one field called 
CONTACT- When a SIP user agent sends a SIP REGISTER message (i.e., a SIP request 
message containing a REGISTER method) to a SIP registrar, depending on the value of the 
CONTACT field of the SIP REGISTER method, the SIP registrar takes different actions. 
Currently RFC 3261 defines two values for the CONTACT field of REGISTER method, 
cither an IP address, or a wild card value, "*". When the contact field is set to the •**" 
wildcard option (value), the registrar clears all the prior registrations of the user from the 
registrar database. 

Since this is standard SIP procedure, one of ordinary skill in this art and 
knowledgeable of SIP operations would know that "adding a registration or handoff option" 
means defining a new option (value) for the CONTACT field of the SIP REGISTER method 
that informs the registrar about a registration caused by a hand off event To respond to the 
Examiner's concerns, however, these claims have been amended to recite, in place of "adding 
a registration or hand off option" "designating an additional option for the CONTACT field 
of the SIP REGISTER method and that indicates registration or hand-off*. 

Applicants appreciate the Examiner's noting applicants* error in claim 13, which has 
been amended to recited "said system comprising". 

Withdrawal of the rejection of claims 2-4, 8-10, and 13-15, as amended, as indefinite 
is therefore requested. 
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In response to the Examiner's rejection of claims 13-15 as non-statutory these claims 
have been amended to recite " a computer readable medium having executable instructions" 
in place of the recitation of " a processor". Withdrawal of the rejection of Claims 13-15, as 
amended, as non-statutory is therefore also requested. 

Accordingly, applicants respectfully submit that claims 2-4, 8-10, and 13-15, as 
amended* are now in condition for allowance. Withdrawal of the Final Rejection* entry of this 
Amendment, allowance of these claims, and passage of this application to issue are therefore 
requested. 

If the Examiner believes it would in any way expedite the prosecution of this 
application, the Examiner is invited to telephone applicants attorney at the number set forth 



below. 



Respectfully submitted, 



Shinichi Babaet al 



A 




RegN^o. 16,154 
Attorney for Applicants 
(732) 699-4465 



Attached 



Fig. 3 
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